Add announcement #6
Conversation
segwit2x-annuncement.md
Outdated
|
|
||
| - Maximum block size doubles from 1,000,000 to 2,000,000. | ||
| - Sig-ops per block doubles from 20,000 to 40,000. | ||
|
|
There was a problem hiding this comment.
Maybe DNS seeds should be mentioned here as well?
segwit2x-annuncement.md
Outdated
|
|
||
| - BTC1: https://github.com/btc1/bitcoin | ||
| - Bitcoin Unlimited: https://www.bitcoinunlimited.info/ | ||
|
|
There was a problem hiding this comment.
Bitcoin classic is also compatible and i think we can expect a patch soon-ish from @zander that enforces a >1MB block
|
ACK so far - pinging some folks for wider comment Will merge in a few days, pending additional comments |
|
Ack |
1 similar comment
|
Ack |
segwit2x-annuncement.md
Outdated
|
|
||
| During the month of November 2017, approximately 90 days after the activation of Segregated Witnesses in the Bitcoin blockchain, a block between 1MB and 2MB in size will be generated by Bitcoin miners in a move to increase network capacity. At this point it is expected that more than 90% of the computational capacity that secures the Bitcoin network will carry on mining on top of this large block. | ||
|
|
||
| The upgrade to 2MB blocks has been agreed first during the [Bitcoin Roundtable Consensus in Hong-Kong](https://medium.com/@bitcoinroundtable/bitcoin-roundtable-consensus-266d475a61ff) on February 2016, and then ratified by the [Bitcoin Scaling Agreement in New York](https://medium.com/@DCGco/bitcoin-scaling-agreement-at-consensus-2017-133521fe9a77) on May 2017. These agreements stipulate the activation of Segregated Witness support and an increase of the maximum block size from 1MB to 2MB. |
There was a problem hiding this comment.
We should use "compatible block size" rather than just "block size", to be clear we're talking about base block size.
There was a problem hiding this comment.
What does compatible mean in this context? Compatible to whom?
segwit2x-annuncement.md
Outdated
|
|
||
| For regular clients: | ||
|
|
||
| - Maximum block size doubles from 1,000,000 to 2,000,000 |
There was a problem hiding this comment.
"compatible block size"
(base block size is also fine with me)
| - OB1: seed.ob1.io | ||
| - Blockchain: seed.blockchain.info | ||
| - Bloq: bitcoin.bloqseeds.net | ||
|
|
There was a problem hiding this comment.
What about the "require a large block on forking point" rule? Clients without this could break away from 2x's consensus.
There was a problem hiding this comment.
Yeah, assuming the hashrate does not follow 2X, but it is not absolutely necessary to add this rule to make clients compatible with the majority hashrate, which is the intention.
There was a problem hiding this comment.
If the majority hashrate ever switches back to mining the non-2x chain, users of software that your checklist considers ready would have the entire 2x history - potentially years of it - wiped out from their clients in a massive reorg. Just puff, and their coins are gone.
Can you guarantee to the users following your "Readiness Checklist" that the mining majority will never switch back? Is that a risk you're willing to take for them?
There was a problem hiding this comment.
Total hashrate in bitcoin doubles every few months. This is likely to continue. 90% hashrate now can be 40% in six months, even if none of the signatories reduce their hashrate.
| ## Incompatible Fully-Validating Node Software | ||
|
|
||
| - Bitcoin Core: https://github.com/bitcoin/bitcoin | ||
| - Bitcoin UASF: http://www.uasf.co/ |
There was a problem hiding this comment.
There are a few more incompatible rule-validating software that you forgot to mention:
- libbitcoin
- bcoin
- btcd
- knots
- bitcore
- haskoin
- nbitcoin
- pynode
- toshi (now retired, but probably still has users?)
Has there been any efforts to reach out to them? Are you okay with leaving users of these implementations behind?
There was a problem hiding this comment.
At the moment I have decided to go for a shorter list of fully-validating nodes that I am sure are compatible or not, and likely to remain so for the foreseeable future, and are frequently used in the wild or otherwise highly relevant. Some of these libraries and clients that you mentioned may deserve their own separate sections in the document. Feel free to submit a pull request with an update to the document if you are sure about 2MB (8MB?)-readiness of each.
There was a problem hiding this comment.
I clarify that with separate sections I mean “libraries” or “wallets” or “lightweight nodes”.
There was a problem hiding this comment.
Note that bcoin, btcd, nbitcoin and knots are full node software, not a library / lightweight wallet.
segwit2x-annuncement.md
Outdated
|
|
||
| ## Readiness Checklist | ||
|
|
||
| The November 2107 upgrade to 2MB blocks is a hard-fork, but necessary changes are trivial to perform. Some SPV clients are expected to work without any change at all. Most clients will need to tweak only two constants to remain compatible with the new larger blocks: |
There was a problem hiding this comment.
November 2107 may be safer timing for this hard fork from the standpoint of users and developers concerned with network stability, but the New York Agreement wants to fork this year, so please change this text to show the aggressive timeline accurately as November 2017.
|
|
||
| ## Readiness Checklist | ||
|
|
||
| The November 2017 upgrade to 2MB blocks is a hard-fork, but necessary changes are trivial to perform. Some SPV clients are expected to work without any change at all. Most clients will need to tweak only two constants to remain compatible with the new larger blocks: |
There was a problem hiding this comment.
The word "necessary" here is misleading because it wrongly suggests that this hard fork is necessary.
There was a problem hiding this comment.
It would be less misleading if it said "politically compulsory" instead.
|
NACK. the readiness checklist is lacking and would put users in severe risks, and the implementation list misses over half of the known implementations. |
|
|
@shesek You are welcome to contribute and improve things! |
No description provided.